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1.   INTRODUCTION 


A  computer-oriented  language  to  describe  and  define  a  digital 
computer  is  developed.   A  description  of  a  digital  computer  in  this 
language  may  be  translated  by  another  computer  into  a  simulator  of  the 
defined  computer.   Alternately,  this  description  may  be  used  as  an 
input  to  a  set  of  automated  design  procedures  to  specify  an  actual  hard- 
ware configuration  of  the  computer. 

A  computer-oriented  language  is  defined  by  a  set  of  rules  which 
determine  how  a  string,  or  sequence  of  characters,  to  describe  a  digital 
computer  may  be  constructed  (syntax)  and  interpreted  (semantics).   Since 
the  language  consists  of  strings  of  characters,  direct  pictorial  description 
of  the  computer  as  input  is  precluded.   The  description  of  the  computer  is 
completely  contained  within  the  language.   Any  natural  language  text  (in 
particular,  English)  included  in  the  description  is  redundant  and  used 
only  for  readability. 

The  proposed  language  is  an  extension  of  ALGOL  60,  augmented  by 
additional  data  and  procedure  declaration  capabilities.   While  the  purpose 
of  the  language  is  to  describe  digital  computer  hardware,  straightforward 
extensions  to  software  applications  are  pointed  out. 

A  number  of  computer-oriented  artificial  languages  for  describing 
computers  have  appeared  in  the  literature  [l,  2,  3>  ^-l-   Although  the  method 
and  scope  of  these  languages  vary  considerably,  their  basic  objectives  are 
similar. 

The  design  of  the  computer-oriented  language  developed  here  is 
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motivated  by  three  primary  goals.   First,  the  language  should  permit  the 
concise  and  unambiguous  documentation  of  a  digital  computer.   A  language 
which  is  easy  to  learn  and  understand,  yet  comprehensive,  will  provide 
for  effective  communication  of  computer  specifications.   In  addition,  a 
good  language  can  assist  the  computer  system  designer  in  the  same  way 
mathematical  notation  aids  the  electrical  engineer  in  circuit  design.   A 
concise  symbolism  saves  time  and  enhances  the  ability  to  find  weaknesses 
in  a  design. 

Secondly,  the  language  may  serve  as  a  source  or  input  language 
to  a  translator  that  produces  a  simulator  of  a  computer  defined  in  the 
language.   The  simulator,  which  runs  on  an  existing  computer,  will  provide 
an  accurate  check  on  the  design  of  the  new  computer  since  it  is  produced 
directly  from  the  definition  of  the  new  computer. 

Finally,  the  description  of  the  actual  hardware  configuration  of 
a  computer  may  be  produced  by  a  "computer  compiler"  from  the  definition  of 
the  computer  in  the  language.   The  description  of  a  new  computer  along  with 
a  statement  of  design  criteria  could  be  used  by  a  set  of  computer  programs 
to  realize  the  new  computer.   The  output  of  these  programs  might  be  l)  boolean 
equations  and  sequencing  information,  2)   logic  drawings,  or  preferably, 
3)  the  actual  specification  of  the  printed  circuit  cards,  location  of  the 
cards  in  bays,  and  wiring  instructions.   Although  certain  guidelines  which 
determine  speed  and  cost  trade  offs  must  be  furnished,  a  computer  program 
can  reasonably  be  expected  to  perform  all  details  of  the  design  procedure. 

There  is  growing  evidence  that  the  specification  of  computer  software 
and  the  specification  of  computer  hardware  share  a  common  spirit  although 
they  diverge  in  implementation.   Computers  which  use  microprogrammed  control 
sequencing  [5,  6]  demonstrate  an  overlap  even  in  implementation.   Based  on 
lis  premise,  the  proposed  language  is  an  extension  of  an  existing  programming 
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language,  ALGOL  60.   The  additions  which  are  made  to  facilitate  hardware 
description  are  equally  applicable  in  software  applications  [7]« 

In  Chapter  2,    a  model  for  information  structures  is  developed. 
The  regular  set  concept  of  automata  theory  is  extended  to  provide  a  model 
for  information  structures  which  are  realizable  by  either  hardware  or 
software.   In  either  realization,  the  model  is  applicable  both  to  storage 
allocation  and  to  information  transfer  and  retrieval  procedures.   Extended 
data  declarations  (Chapter  3)>  variables  (Chapter  h) ,    and  procedure 
declarations  (Chapter  5)  are  then  developed  for  modification  of  ALGOL  6o. 
ALGOL  60  itself  is  not  discussed  here  [8],   Use  of  the  proposed  language 
to  describe  a  simple  computer  is  illustrated  in  Chapter  6.   Implementation 
of  the  proposed  language  is  discussed  in  Chapter  7* 


2.   INFORMATION  STRUCTURES 

2.1  Regular  Sets 

Although  equivalent  formulations  of  regular  sets  will  be  found 
in  the  literature  of  automata  theory  [9* 10],  we  will  define  regular  sets 
here  as  sets  of  strings  over  a  finite  alphabet  Z  generated  as  follows : 
i.   A  set  containing  a  single  string  which  is  just  one 
letter  of  the  alphabet  Z  is  a  regular  set.   The  null 
set,  i.e.  the  empty  string  containing  no  letters,  is 
also  considered  to  be  a  regular  set. 
ii.   If  A  and  B  denote  regular  sets  then  the  concatenation 
of  A  and  B,  denoted  AB,  is  a  regular  set.   AB  consists 
of  all  strings  formed  by  concatenating  an  element  of  A 
with  an  element  of  B  such  that  the  element  of  A  is  on 
the  left, 
iii.   If  A  and  B  denote  regular  sets  then  the  disjunction 

of  A  and  B,  denoted  A  v  B,  is  a  regular  set.   A  v  B  is 
the  set  of  all  strings  contained  in  either  A  or  B, 
i.e.,  the  set  theoretic  union  of  A  and  B. 
iv.   If  A  is  a  regular  set  then  the  iterate  of  A,  denoted 
A*  is  a  regular  set.   A*  is  the  infinite  set  of  all 
strings  of  finite  length  formed  by  the  concatenation 
of  strings  from  the  set  A.   Hence  A*  consists  of  all 
strings  of  the  following  form: 

a,   a1,  o.^a2,   a^cyx^,  .  .  . 
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where  (X   is  the  null,  or  empty,  string  and  each  a     is  a 
string  from  the  set  A. 

The  expression  (abc  v  db)*a,  for  example,  denotes  a  regular  set 
of  strings  over  the  alphabet  a,  b,  c,  and  d.   By  rule  i  above,  a,  b,  c 
and  d  are  regular  sets.   By  rule  ii,  abc  and  db,  and  hence  by  rule  iii, 
(abc  ^  db)  are  regular  sets.   Finally,  by  rule  iv  (abc  ^  db)*  and  hence 
(abc  v-  db)*a  are  regular  sets.   Members  strings  of  (abc  v  db)*a  include 
abca,  a,  abcabcdbabca,  dbabca,  and  dbdbdbdba.   The  strings  db  and  aba  are  not 
strings  of  (abc  v  db)*a. 

Regular  sets  are  just  those  sets  of  strings  which  may  be  classified 
by  a  finite  state  machine;  they  include  all  finite  sets  and  many  infinite 
sets  of  strings.   The  properties  of  regular  sets  have  been  thoroughly 
discussed  in  the  literature. 

The  expressions  which  are  formed  by  joining  the  letters  of  the 
alphabet  E  with  the  operations  of  concatenation,  disjunction,  and  iteration 
according  to  the  definition  of  regular  sets  are  called  regular  expressions. 


2.2  Structure  Sets 

The  concepts  of  regular  sets  and  regular  expressions  will  now  be 
extended  to  provide  a  model  for  information  structures.   Instead  of  symbols 
or  letters  we  will  let  the  alphabet  Z  designate  a  set  of  information  cells. 
The  members  of  L   are  distinguishable  by  the  amount  of  information  which  each 
represents.   In  the  simplest  instance,  each  member  of  Z  may  denote  an 
information  cell  containing  exactly  n  bits--one  and  only  one  member  for 
every  positive  integer  n  <  N,  for  some  given  N.   In  general,  each  regular  set 
now  denotes  a  number  of  alternate  sequences  of  information  cells,  although 
a  unique  sequence  may  be  denoted.   The  fact  that  only  sequences  of  information 
or  data  cells  can  be  defined  is  not  a  serious  restriction  of  the  model  since 
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any  usable  data  structure  can  always  be  mapped  into  a  sequence  of 
information  cells,  such  as  consecutive  words  of  a  memory  addressed  by 
a  sequence  of  integers. 

If  we  let  the  symbol  (n)  denote  an  information  cell  containing 
n  bits  where  n  is  an  integer,  we  may  define  sets  of  sequences  of  information 
cells  by  means  of  regular  expressions  on  the  alphabet  {(n)).   (l)(3)(5) 
and  ((l)(U)  v  (3))*  are  examples. 

An  information  structure,  however,  consists  of  more  than  just  a 
sequence  of  information  cells.   The  grouping  and  internal  structure 
associated  with  a  sequence  of  cells  is  an  integral  part  of  an  information 
structure.   This  additional  property  can  be  derived  from  the  format  of 
the  regular  expression.   In  particular,  we  will  consider  parentheses  used 
in  regular  expressions  to  be  essential  to  the  specification  of  information 
structure.   Parentheses  specify  hierarchial  level  of  substructures  in  the 
information  structure.   A  regular  expression  considered  in  this  manner 
to  define  information  structures  will  be  called  a  structure  expression. 

To  aid  in  the  interpretation  of  structure  expressions  we  will 
associate  a  unique  tree  with  each  structure  expression.   Structure 
expressions  which  differ  only  in  parentheses  normally  define  different  trees. 
Each  explicit  pair  of  parentheses  (a  right  parenthesis  and  its  corresponding 
left  parenthesis  in  the  structure  expression)  defines  a  node  of  the  tree. 
An  implicit  pair  of  parentheses  embracing  the  entire  expression  defines  the 
root  node.   The  parenthesis  pairs  embracing  an  integer  in  the  alphabet 
{(n)}  define  terminal  nodes  of  the  tree.   Additional  implicit  parentheses 
may  be  assumed  by  the  precedence  of  operators  as  discussed  below.   If  a 
sequence  of  parentheses  pairs  are  contained  immediately  within  a  parentheses 
pair,  the  outer  pair  is  the  parent  node  while  the  inner  parentheses  pairs 
are  sibling  nodes  connected  by  branches  to  the  parent  node.   The  sibling 
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nodes  are  ordered  left  to  right  in  correspondence  with  the  ordering 
inner  parenthesis  pairs. 

In  general,  every  adjacent  pair  of  parenthesis  pairs  in  a 
sequence  of  parenthesis  pairs  will  be  separated  by  an  operator  (concatenation, 
disjunction,  or  iteration).   A  sequence  of  parenthesis  pairs  may  be 
sibling  nodes  of  the  same  parent  node  only  if  the  parenthesis  pairs  are 
all  separated  by  a  concatenation  operator  (juxtaposition)  or  all  separated 
by  a  disjunction  operator  (v).   If  this  condition  is  not  satisfied,  additional 
parentheses  will  automatically  be  assumed  according  to  the  following  rule: 
the  operation  of  iteration  takes  precedence  (lower  hierarchial  level  in  the 
tree)  over  concatenation  which  in  turn  takes  precedence  over  disjunction. 
Each  time  the  operation  of  iteration  occurs  a  new  node  is  implied.   This 
new  node  has  only  one  sibling  node--the  node  corresponding  to  the  expression 
iterated. 

Although  each  node  corresponding  to  iteration  has  only  one  sibling 
node,  it  is  equivalent  to  an  infinite  number  of  sibling  nodes  joined  by 
disjunction.   Each  of  these  sibling  nodes  in  turn  corresponds  to  a  finite 
concatenation  of  the  single  sibling  node.   In  selecting  a  particular 
member,  one  of  the  concatenated  nodes  must  be  selected.   For  example,  the 
structure  expression 

(  (3)(*0  )(  (1)(6)(3)  )  -  (  (5)  -  (2)  )  *  (9)  -  (1) 

has  the  tree  shown  in  Figure  1. 

The  single  structure  defined  by  (  (3)(^)  )(  (l)(6)(3)  )  i-s  one 
member  of  the  set  of  structures  defined  by  the  example.   The  corresponding 
tree  is  given  in  Figure  2.    Another  member  which  demonstrates  the  selection 
of  a  member  of  an  iterated  substructure  is  (  (5) (2) (5) (5)  )(9)  whose  tree 
is  given  in  Figure  3 

In  summary,  every  structure  expression  defines  a  set  of  sequences 
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(3)  (4)  (I)  (6)  (3) 


(5)  (2) 


FIGURE     I.         THE    TREE     CORRESPONDING     TO 
((3)(4))((l)(6)(3)v((5)v(2))*(9)v(|). 


(3)  (4)  (I)  (6)  (3) 


FIGURE     2.        THE    TREE     CORRESPONDING     TO 
((3)(4))((l)(6)(3)). 
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(5)  (2)  (5)  (5) 


FIGURE     3.      THE     TREE    CORRESPONDING     TO 
((5)  (2)  (5)  (5))  (9). 


FIGURE     4.       A    REPRESENTATION     OF 
(((8)v(|6))D*. 
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of  information  cells.   In  addition,  every  structure  expression  has  a  unique 
corresponding  tree.   Each  member  of  a  structure  set  contains  one  sequence 
of  information  cells  and  has  a  unique  associated  subtree.   Further,  this 
subtree,  and  its  corresponding  structure  expression,  may  be  derived 
directly  from  the  parent  tree. 

We  will  define  an  idealized  information  structure  as  a  tree 
corresponding  to  a  structure  expression  which  defines  a  single  sequence  of 
information  cells.   Any  set  of  information  structures  which  may  be  defined 
by  an  arbitrary  structure  expression  will  be  called  a  structure  set . 

A  structure  expression  may  alternatively  be  viewed  as  a  generative 
grammar.   The  sentences  generated  by  the  grammar  correspond  to  individual 
sequences  of  information  cells.   The  set  of  all  information  cell  sequences 
corresponds  to  the  language  generated  by  the  grammar.   An  information  structure 
then  corresponds  to  a  p-marker  or  derivation  in  the  grammar  while  a 
structure  set  corresponds  to  the  set  of  all  p-markers  which  may  be  obtained 
from  the  grammar.   Concepts  such  as  equivalence  of  grammars  also  carry  over 
to  structure  expressions.   Two  structure  expressions  are  strongly  equivalent 
if  they  define  the  same  set  of  information  structures  and  are  weakly  equiva- 
lent if  they  define  the  same  set  of  sequences  of  information  cells. 


2.3  Interpretation  of  Structure  Sets 

A  structure  set,  defined  by  a  structure  expression  which  uses  only 
concatenation,  defines  a  set  containing  only  one  information  structure.   This 
class  of  expressions  generally  defines  single  registers  and  their  organization 
in  hardware  applications.   Similarly,  in  software  applications,  arbitrary 
arrays  are  defined  by  first  grouping  the  cells  into  rows,  then  the  rows  into 
a  two  dimensional  array,  and  so  on  for  each  additional  dimension.   In 

ral,  a  single  finite  sequence  of  information  cells  with  any  grouping 
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arrangement  of  neighboring  cells  or  groups  of  cells  may  be  specified  by 
using  only  concatenation. 

The  use  of  disjunction  in  structure  expressions  permits  the 
specification  of  a  set  of  alternate  structures.   By  using  disjunction  at 
various  levels  within  the  structure  expression  the  alternate  structure 
can  generally  be  defined  without  enumerating  all  possibilities.  Alternate 
structures  are  specified  by  a  data  declaration  with  the  understanding  that 
only  one  structure  of  the  set  exists  in  any  one  instance.   In  another 
instance  a  different  structure  from  the  set  might  be  selected.   In  software 
applications,  choice  of  an  alternate  structure  may  either  reallocate 
memory  or  reassign  or  reorganize  the  existing  data  structure.   In  hardware 
applications,  alternate  structures  are  limited  to  reorganization  or 
reconnection  of  registers  or  equivalent  memory. 

The  iterate  A*  of  a  specified  structure  set  A  is  interpreted  as  a 
stack.   Each  cell  of  the  stack  is  a  valid  information  structure  from  the 
structure  set  A  which  is  iterated.   An  inexhaustible  supply  of  available 
empty  cells  which  are  added  to  the  stack  as  required  is  assumed.   Hence 
the  iterate  of  a  structure  set  A,  A*,  denotes  a  finite  unbounded  sequence 
(possible  empty)  of  cells  from  the  structure  A  which  corresponds  to  the 
programming  concept  of  a  stack. 

In  software  applications,  the  data  structure  defined  by  an  iterated 
structure  need  not  necessarily  be  a  consecutive  sequence  in  storage.   For 
example,  the  structure  set, 

(((8)v  (16))  *)  *, 
implies  a  stack  of  stacks  where  the  cells  of  the  internal  stacks 
contain  either  8  or  l6  bits .   The  actual  implementation  of  this  structure 
might  be  a  linked  list  structure  using  additional  information  cells  or  link 
cells  to  name  the  next  consecutive  sub-information  structure  or  data  cell. 
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This  structure  set  might  then  be  represented  as  shown  in  Figure  k. 
Hardware  implementation  of  arbitrary  structure  expressions  using  iteration 
will  in  general  require  a  combination  of  hardware  and  software  or  micro- 
programming techniques. 


3-   DATA  DECLARATIONS 

Additional  data  declarations  will  now  be  developed  to  augment 
the  ALGOL  60  data  declarations.   These  declarations,  the  format  declaration 
and  the  field  declaration,  are  based  upon  the  information  structure  model 
developed  in  the  last  chapter. 


3-1  Orientation 

Both  format  and  field  declarations  are  specified  by  format 
expressions,  which  implement  and  generalize  the  concept  of  structure 
expressions  in  the  computer-oriented  language.  Format  expressions  will  be 
built  up  from  a  set  of  terminal  units  by  concatenation  and  disjunction  in 
a  manner  similar  to  the  way  in  which  boolean  expressions  are  introduced  in 
ALGOL  60.   Iteration  will  be  reintroduced  into  the  language  in  Chapter  7. 

When  a  field  is  declared,  a  register  or  mutable  memory  element 
is  allocated.   This  memory  will  agree  in  number  of  bits  and  format  with 
that  specified  by  the  corresponding  format  expression. 

A  format  declaration,  on  the  other  hand,  does  not  declare  a 
physical  memory  counterpart.  A  format  declaration  defines  only  a  generalized 
information  structure  detached  at  the  time  of  declaration  from  any  specific 
register  or  memory  realization.  A  declared  format  may  be  referred  to  in 
a  field  declaration.  At  this  time,  memory  will  be  assigned  in  accordance 
with  the  declared  format.   Formats  also  appear  in  procedure  declarations 
(cf.  Chapter  5)  to  specify  the  formats  of  formal  parameters  and  function 
identifiers;  the  information  formats  of  buses,  input  lines  and  output  lines 
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can  be  described  in  this  manner. 


3.2   Syntax 

The  syntax  for  data  declarations  will  be  given  in  Backus  Normal  Form. 
We  assume  here  that  the  reader  is  familiar  with  the  specification  of  ALGOL  60 
as  defined  in  the  "Revised  Report  on  the  Algorithmic  Language  -  ALGOL  60"  [8]. 
1)  ^declaration  "  =      <type  declaration 

|<array  declaration 
|<switch  declaration> 
[<procedure  declaration> 
|<format  declaration> 
|<field  declaration> 
This  syntatic  definition  adds  format  and  field  declarations  to  the  set  of  ALGOL 
60  declarations.   Procedure  declarations  are  extended  for  compatability  in 
Chapter  5.   The  syntax  and  semantics  of  the  remaining  declarations  are  as  given 
in  the  ALGOL  60  report. 


2)  <format  declaration> 


3)  <field  declaration> 


U)  <format  expression> 


5)  <format  term> 


FORMAT  <format  expression> 
I FORMAT  <formal  expression>  OR 

<format  declaration> 
FIELD  <format  expression> 
[FIELD  <format  expression>  OR 

<field  declaration> 
<format  term> 

|<format  expression,  <format  term> 
<format  secondary> 
|<if  clause>  <format  secondary> 
|<if  clause>  (<format  secondary>) 
ELSE  <format  term> 
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7)  <format  primary> 


6)  <format  secondary>     : :=      <format  primary> 

|<format  primary>  *  <arithmetic 

expression> 
|<literal> 
: :=      <format  label  part>  [<arithmetic 
expression>] 
|<format  identifier> 
|<format  label  part>(<format 
expression>) 
:  :=       <empty> 

|<format  label> 

|<letter  string>  :<format  label  part> 
<empty>  denotes  an  empty  sequence  of  symbols 


8)  <format  label  part> 


9)  <format  label> 


10)  <literal> 


11 )  <bit  string> 


12)  <field  identifier^ 

13)  <format  identifier> 


<format  identifier^ 
|<field  identifier> 
|<procedure  identifier> 
|<formal  parameter> 

•<bit  string>' 
I '<bit  string>  [arithmetic 

expression>] ' 
|<literal>  <literal> 
I '<literal>  [arithmetic  expression>] 

0|l 

|<bit  stringX) 
|<bit  string>l 
<identifier> 
<identifier> 


«&•: 
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The  syntax  and  semantics  of  <if  clause>,  <arithmetic  expression^ 
<letter  string>,  and  <identifier>  are  the  same  as  for  ALGOL  60  and  will  not 
be  redefined  here. 


3-3  Semantics 

3- 3-1  Format  Primaries 

Format  primaries  define  and  label  component  information  structures 
which  in  turn  can  be  combined  into  larger  information  structures.   Each  format 
primary  defines  a  component  information  structure  in  one  of  three  ways.   An 
arithmetic  expression  enclosed  in  square  brackets  denotes  a  single  information 
cell  containing  the  number  of  bits  indicated  by  the  arithmetic  expression. 
Secondly,  a  format  primary  may  be  the  name  of  a  previously  defined  format. 
Finally  the  format  primary  may  be  a  format  expression,  which  is  itself 
composed  of  format  primaries. 

Each  format  primary  creates  a  node  in  the  tree  of  the  information 
structure  being  defined.   If  the  primary  is  a  single  information  cell  then 
a  terminal  node  of  the  tree  is  indicated.   If  the  primary  is  a  previously 
defined  format,  the  tree  corresponding  to  that  format  is  included  in  the 
structure,  headed  by  that  node.   A  format  expression  as  a  primary  creates  a 
nonterminal  node  in  the  tree.   The  branches  from  this  node  will  in  turn 
be  determined  by  decomposition  of  the  format  expression. 

A  format  primary  may  also  assign  a  label  or  name  to  each  created 
node.   Any  ALGOL  identifier  may  appear  in  the  label  part  which  will  serve 
to  identify  the  corresponding  node  in  all  future  references  to  that  node. 
A  letter  string  followed  by  a  colon  preceding  the  identifier  in  the  label 
part  is  treated  as  explanatory  labeling  and  has  no  further  interpretation. 

If  the  format  expression  appears  in  a  field  declaration,  the 
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identifier  appearing  in  the  label  part  is  declared  as  a  field  identifier. 
Since  a  field  declaration  allocates  storage  corresponding  to  the  information 
structure ,  the  field  identifier  references  storage  corresponding  to  the  node 
designated  by  the  primary.   When  the  format  expression  appears  in  a  format 
declaration  the  identifier  is  declared  to  be  a  format  identifier.   The 
format  identifier  labels  the  corresponding  node  of  the  tree  but  does  not 
reference  any  storage  at  this  time.   If  the  format  identifier  is  used  as  a 
primary  in  format  expression  of  another  declaration,  the  format  identifier 
then  becomes  a  label  of  the  corresponding  node  in  that  declaration.   If  the 
latter  declaration  is  a  field  declaration,  the  format  identifier  and  all  other 
identifiers  in  the  tree  headed  by  the  format  identifier  become  field  identifiers 
labeling  the  corresponding  storage  allocated  by  the  field  declaration.   Note 
that  the  same  format  may  be  used  in  many  field  declarations  to  allocate 
independent  storage.   To  prevent  ambiguity  in  designation,  additional  labeling 
conventions  are  given  in  Section  3«3«6. 


3-3-2  Format  Secondaries 

A  format  secondary  may  simply  be  a  format  primary,  a  format  primary 
repeated  an  integral  number  of  times,  or  a  literal- 

The  repetition  of  the  same  structure  consecutively  is  common  in 
digital  computers  and  hence  is  worth  special  notation.   The  structure  specified 
by  the  format  primary  preceding  the  asterisk  is  repeated  (concatenated  with 
itself).   The  number  of  times  is  specified  by  the  arithmetic  expression.   Note 
that  this  operation  is  not  the  operation  of  iteration. 

A  format  secondary  may  also  be  a  literal  which  is  an  unalterable 
information  structure  having  a  specified  bit  pattern.   The  literal  is  defined 
by  specifying  the  bit  pattern.   The  use  of  arithmetic  expressions  in  specifying 
literals  permits  a  bit  pattern  or  literal  to  be  repeated  consecutively  the 
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number  of  times  specified  by  the  arithmetic  expression. 

Literals  represent  permanent  or  fixed  memory  in  field  declarations, 
and  have  a  similar  meaning  in  format  declarations. 

3.3.3  Format  Terms 

The  operation  of  disjunction  in  structure  expressions  is  implemented 
through  format  terms.   Each  format  term  represents  a  sequence,  possibly  null, 
of  disjunctions.   Alternate  format  secondaries  are  separated  by  if  clauses 
which  determine  which  of  the  alternates  is  to  be  selected.   The  boolean 
expressions  associated  with  the  if  clauses  are  evaluated  sequentially.   The 
first  format  secondary  for  which  the  corresponding  boolean  expression  is  true 
is  the  one  selected.   If  no  secondaries  can  be  selected  then  the  term 
corresponds  to  an  empty  information  cell. 

A  field  declaration  may  only  appear  at  the  beginning  of  an  ALGOL 
block.   Each  time  an  ALGOL  block  is  entered,  the  format  terms  of  a  field 
declaration  are  reevaluated.   Hence  the  memory  defined  by  the  field  declaration 
may  change  dynamically.   This  is  not  to  say  that  the  registers  or  memory 
change  physically  but  they  may  be  logically  reconnected  or  restructured 
dynamically. 

Format  declarations  are  evaluated  each  time  they  are  referred  to. 
A  previously  defined  format  appearing  in  a  field  declaration  is  reevaluated 
every  time  the  block  embracing  the  field  declaration  is  entered.   A  format 
declaration  appearing  in  a  procedure  declaration  is  reevaluated  each  time  the 
procedure  is  called. 


3-3-^  Format  Expressions 

The  operation  of  concatenation  in  structure  expressions  is  implemented 
at  expressions.   A  format  expression  may  consist  of  a  single 
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format  term  or  a  finite  sequence  of  format  terms  separated  by  commas.   Each 
comma  is  equivalent  to  the  operation  of  concatenation. 


3.3.5  Format  and  Field  Declarations 

A  field  declaration  is  formed  by  preceding  a  format  expression  with 
the  word  FIELD,  while  a  format  declaration  is  formed  by  preceding  a  format 
expression  by  the  word  FORMAT.   In  each  case  the  format  expression  defines 
the  structure  and  labeling  of  the  format  or  field  declared. 

A  finite  sequence  of  format  or  field  declarations  separated  by  the 
word  OR  provide  yet  another  form  of  disjunction.   While  format  terms  permit 
selection  of  alternate  structures,  only  one  structure  is  valid  at  any  given 
time.   All  alternate  declarations  separated  by  OR  define  alternate  structures 
for  the  same  format  or  field  and  are  simultaneously  valid.   In  this  sense, 
information  may  be  considered  to  be  contained  in  a  single  sequence  of  bits 
to  which  a  number  of  alternate  structures  are  applicable.   The  alternate 
structures  are  distinguished  solely  by  their  labeling. 

Each  declaration  in  the  sequence  is  independent,  but  must  specify 
the  same  number  bits.   The  separation  of  the  declarations  by  OR  signifies 
that  they  pertain  to  the  same  format  or  field.   The  first  declaration  in 
the  sequence  will  be  called  the  principal  structure  and  its  significance  will 
become  apparent  in  the  next  chapter. 

3-3-6  Labeling 

Each  label  associates  an  identifier  with  a  node  of  the  tree  corresponding 
to  the  defined  information  structure.   For  example,  the  tree  corresponding  to 
the  format  expression, 

A(AA(BA(CA[3],  [5])*2),  BB(CA[2],  CC[6])) 
is  shown  in  Figure  5- 
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(2)  (6) 


FIGURE     5.  THE     TREE     CORRESPONDING     TO 

A(AA(BA(CAC33,    C51)  *  2),    BB(CAC2:,  CCC61)). 
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FIGURE     6.  THE     REGISTER     FORMAT     CORRESPONDING     TO 

A(AA(BA(CAC3],  [5])*  2),    BB(CAC2],  CCC6])). 


-21- 


Alternately  the  expression  could  also  be  drawn  as  shown  in  Figure  6,  which 
more  graphically  represents  an  actual  memory  or  register  format.   Identifiers 
must  uniquely  denote  a  single  sub -information  structure.   However  the 
identifiers  themselves  need  not  be  unique.   In  general,  the  identifiers  of 
higher  level  nodes  will  be  required  to  distinguish  between  identifiers  of 
lower  level  nodes,  as  for  example,  BA  and  BB  are  required  to  distinguish 
between  the  fields  identified  by  CA.   When  an  information  structure  is 
duplicated  an  integral  number  of  times  the  component  substructures  must  be 
distinguished  by  indexes  as  are  BA„  and  BA,  •   The  format  expression 

A([3],  IF  N  >  2  THEN  B[N]  ELSE  B[2]  ) 
is  permitted  since  at  any  given  time  either  B[N]  is  valid  or  B[2]  is  valid 
depending  on  the  value  of  N. 

In  summary,  every  labeled  format  primary  introduces  a  new  level  of 
labeling  which  permits  any  identifier  to  be  used  within  that  primary  provided 
it  is  unique  within  that  level  of  labeling.   Similarly,  the  labeling  of  each 
format  secondary  within  the  same  format  term  is  independent  of  the  labeling 
within  the  other  secondaries. 


k .   VARIABLES 

Variables  are  the  means  of  accessing  defined  information 
structures.  A  field  variable  is  added  to  the  ALGOL  set  of  variables  to 
reference  the  additional  information  structures  which  can  be  defined  in 
this  language.   Field  variables  may  be  used  in  any  statement  where  ALGOL 
permits  the  use  of  simple  or  subscripted  variables. 


k.l     Syntax  of  Variables 
l)  <variable> 


: :=     <simple  variable> 

| Subscripted  variable> 
|<field  variable> 
::=     <field  segment> 

|<field  variable>  |   <field 
segment> 
The  symbol  I   denotes  concatenation 


2)  <field  variable> 


3)  <field  segment> 


k)     <field  specifier  list> 


5)  <field  specif ier> 


<literal> 

|<field  specifier  list> 
<field  specifier> 
|<function  designator>  [<field 

subscript  list>] 
<field  specifier  list>  .  <field 

specifier> 
<field  identifier> 
<field  identified  [<field 

subscript  list>] 
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6)   <field  subscript  list> 


7)  <field  subscript> 


<field  subscript> 
I  <f ield  subscript  list>,  <f ield 
subscript> 
<arithmetic  expression> 
|  <arithmetic  expressions 
<arithmetic  expression> 


U.2  Semantics  of  Variables 
1+.2.1  Field  Variables 

Field  variables  are  formed  by  concatenating  a  sequence  of  field 
segments.   Each  field  segment  either  is  a  literal  (as  defined  in  Section 
3.3.2)  or  designates  some  portion  of  a  declared  field  or  formated  function 
designator  by  means  of  a  field  specifier  list.   In  this  manner,  portions 
of  various  registers  and  other  information  sources  can  be  connected  together 
along  with  constants  (literals)  to  form  one  variable  or  information  source. 
A  variable  may  be  formed  from  a  number  of  structures  or  from  a  single 
information  structure  which  is  decomposed  and  reassembled  in  another  order. 

!+.2.2  Field  Specifier  List 

A  field  specifier  list  is  a  sequence  of  field  specifiers  separated 
by  the  punctuation  ".".   A  field  specifier  list  designates  a  substructure 
of  a  declared  information  structure  by  naming  successive  substructures  in 
the  tree  corresponding  to  the  structure.   The  first  field  specifier  in  the 
list  must  uniquely  designate  an  information  structure  or  substructure.   Each 
succeeding  field  specifier  in  sequence  designates  successive  substructures. 

Since  the  identifiers  naming  substructures  are  not  necessarily 
unique  to  one  information  structure,  a  sequence  of  field  specifiers  will 
often  be  required  to  uniquely  designate  one  information  field.   Only  as 
many  field  specifiers  need  to  be  used,  however,  as  are  required  for 
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uniqueness . 

A  function  designator,  with  or  without  a  subscript  list,  may- 
appear  as  the  first  field  specifier  in  the  field  specifier  list.   The 
remaining  field  specifiers  in  the  list  must  then  refer  to  a  format 
which  has  been  assigned  to  the  function  designator  in  its  declaration. 
An  access  function  designator  beginning  a  field  specifier  list  is  treated 
the  same  as  a  field  identifier;  it  differs  only  inasmuch  as  the  procedure 
must  be  executed  to  retrieve  the  information.   If  the  variable  appears  in 
the  left  part  of  an  assignment  statement,  indicating  a  value  is  to  be 
assigned  to  the  variable,  the  function  designator  can  only  be  a  store 
procedure  identifier;  otherwise  the  function  designator  can  only  be  an 
access  procedure  identifier.   A  store  and  an  access  procedure  having  the 
same  identifier  can  then  be  distinguished  in  this  manner. 


U.2.3  Field  Subscript  List 

A  field  specifier  may  be  a  single  field  identifier  or  it  may  be  a 
field  identifier  followed  by  a  field  subscript  list  enclosed  in  square 
brackets.   The  field  identifier  specifies  a  sub-tree  headed  by  the  node 
with  the  corresponding  identifier.   A  subscript  list,  following  the 
identifier,  selects  a  sub-tree  of  this  sub-tree.   The  first  subscript  in 
the  list  selects  a  number  of  branches  from  the  identified  node.   Each 
succeeding  subscript  in  the  list  selects  branches  from  the  next  lower  level 
ode  --  the  nodes  on  each  of  the  branches  selected  by  the  previous  subscript. 
Each  subscript  is  either  a  single  arithmetic  expression  or  two 
arithmetic  expressions  separated  by  a  colon.   A  single  arithmetic  expression 
signates  a  single  branch  --  the  branch  whose  index  is  the  value  of  the 
unetic  expression.   The  indexing  begins  with  the  integer  "0".  When  the 
:  expre:      are  used,  the  first  designates  the  first  branch 
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tc  be  selected  and  the  second  arithmetic  expression  designates  the  number 
of  consecutively  higher  indexed  branches  to  be  selected,  including  the 
first  branch. 

For  example,  given  the  format  expression 

A(B(C((([3],  ft])*3)2),  [2]>  C  [3]), 
whose  tree  is  given  in  Figure  7 >    the  field  variable,  B.C[0:2,  1,  1,  0:3]; 
designates  the  sub-  information  structure  indicated  in  Figure  8  where  only 
the  first  3  bits  of  the  four  bit  cell  are  included. 

When  a  sequence  of  alternate  field  or  format  declarations, 
separated  by  OR,  define  alternate  structures  for  the  information  source, 
identical  labeling  may  also  be  used  to  reference  the  same  information  in 
many  of  the  alternate  declarations.   The  labels  are  not  multiply  defined 
since  they  refer  to  the  same  information  even  though  they  may  have  alternate 
structures.   When  these  labels  are  subscripted  in  variables,  however, 
ambiguity  may  arise.   The  ambiguity  will  always  be  resolved  by  consulting 
the  first  or  principal  declaration  in  the  sequence. 

For  example,  let  the  following  field  declaration  be  given 
FIELD  A([3]*2,  [3]*3,  [3]*2)  OR  FIELD  A  (B  (C[3L  D[6]),  E[6],  F[6]. 
The  corresponding  trees  are  given  in  Figures  9  and  10  respectively;  the 
variable  A  [1:2]  denotes  the  sub--tree  of  this  tree  as  given  in  Figure  11. 
The  same  sequence  of  information  cells  could  also  be  designated  by  the 
variable,  D[3=3]  |  |  E  |  |  F. 

h.2^h     Interpretation  of  Variables 

The  purpose  of  a  variable  is  to  reference  a  declared  information 
structure.   The  designated  accessed  information  is  considered  as  a  single 
sequence  of  bits  without  regard  to  structure.   If  the  variable  appears  in  a 
boolean  expression  or  in  an  equality  relation,  then  the  variable  is  considered 
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(3)  (4)  (3)  (4)  (3)  (4)  (3)  (4)  (3)  (4)  (3) 


FIGURE     7.         THE     TREE     CORRESPONDING     TO 
A(B(C(((C3],   [4])*3)*2),    C21),    CC31). 


FIGURE     8.        THE     SUB -TREE     ACCESSED     BY     THE 
VARIABLE     B.     CCO=2,  I,  I,  0=33. 
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(3)     (3)     (3)    (3)     (3)     (3)     (3) 


FIGURE  9.   THE  TREE  CORRESPONDING  TO 
A([3]*2,  C3]*3,  C3]*2). 
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FIGURE  10.   THE  TREE  CORRESPONDING  TO 
A(B(CC3],  DC6]),  EH6],  FC6]). 


(3)  (3)  (3)  (3)  (3) 


FIGURE     II. 


THE     SUB-TREE     ACCESSED     BY     ACh2D 
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as  a  bit  sequence  with  the  operation  applying  to  individual  bits.   If  the 
variable  appears  in  an  arithmetic  expression  or  in  a  relation  (<,  >,  >,  or  >) 
then  the  variable  is  considered  to  be  the  integer  corresponding  to  the  bit 
sequence.   When  the  variable  appears  in  the  left  part  of  an  assignment 
statement,  the  information  is  transferred  to  the  substructure  designated 
by  the  variable  as  a  bit  string;  any  other  form  of  information  is  converted 
to  a  bit  string  before  the  transfer. 


5-   PROCEDURE  DECLARATIONS 


Store  and  access  procedures  are  introduced  to  facilitate  storage 
and  retrieval  procedures  respectively.   An  access  procedure  is  similar  to 
real,  boolean,  or  integer  procedures  of  ALGOL  60.   Here  however  the 
value  of  the  function  designator  is  an  arbitrary  information  structure  rather 
than  restricted  to  real,  boolean,  or  integer  type.   A  store  procedure  can 
appear  only  in  the  left  part  of  an  assignment  statement  and  serves  the 
opposite  purpose  of  that  of  an  access  procedure.   ALGOL  procedures  and 
functions  are  also  augmented  by  permitting  formal  parameters  to  be  specified 
by  formats  as  well  as  by  the  usual  ALGOL  specifiers. 


5-1  Syntax 

1)  <procedure  declaration>  : :=  <procedure  type>  PROCEDURE 
<procedure  heading>  <procedure  body> 

2)  <procedure  type>  :  :=  REAL  |  BOOLEAN   INTEGER  |  <empty> 

|  ACCESS  |  STORE 

3)  <procedure  heading>  : :=  <procedure  identifier>  <formal 
parameter  part>;  <value  part>  Specification  part> 

h)     Specification  part>  :  :=  <empty>  |  <specifier>  <identifier 
list>;  i  <specification  part>  <specifier>  <identifier  list>; 
|  <format  specification^   <specification  part>  <format 
specification^ 
5)  <format  specification>  : '.-   <format  declaration> 
This  syntax  is  essentially  the  same  as  the  procedure  declaration 
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syntax  of  AKOL  60.   Definition  2)  introduces  STORE  and  ACCESS  as  procedure 
types  and  k)   permits  format  declarations  as  specifications  in  the 
specification  part  of  a  procedure  declaration. 

For  syntax  of  procedure  identifier^  <formal  parameter  part>, 
<value  part>,  <specifier>,  and  identifier  list>  see  the  revised  AICOL  60 
report  [8]  . 

5.2  Semantics 

5.2.I  Formal  Parameters 

The  formal  parameters  of  procedures  and  functions  in  AI£0L  60  may 
only  he  specified  as  boolean,  real,  or  integer  by  the  AI£0L  specifiers, 
in  addition,  the  proposed  language  permits  arbitrary  structure  to  be  assigned 
to  formal  parameters.   The  structure  is  assigned  by  a  format  specification 
in  the  specification  part  of  the  procedure  declaration.   The  format  specification 
consists  of  a  format  declaration  in  which  one  primary  is  labeled  with  the 
identifier  of  the  formal  parameter. 

When  a  formal  parameter  in  a  procedure  is  specified  as  a  format 
as  distinct  from  real,  boolean,  or  integer,  the  actual  parameter  which 
replaces  the  formal  parameter  when  the  procedure  is  executed  must  consist  of 
a  compatible  number  of  bits.   The  structure  of  the  actual  parameter,  however, 
need  not  be  the  same  as  the  specified  structure  of  the  formal  parameter. 
Upon  execution  of  the  procedure  the  actual  parameter  will  be  converted  to  a 
bit  string;  the  tree  structure  and  labeling  of  the  formal  parameter  will  be 
assigned  to  the  actual  parameter.   In  this  sense,  an  automatic  conversion  of 
type  takes  place  when  an  actual  parameter  replaces  a  formated  formal 
parameter  (either  by  name  or  by  value)  in  the  call  of  a  procedure  or 

.   This  conversion  of  type  (format)  only  takes  place  when  the 
parameters  are  compatible  in  number  of  bits.   They  are  compatible  when  the 
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selected  format  of  the  actual  parameter  has  the  same  number  of  bits  as  the 
selected  format  of  the  formal  parameter.   The  format  of  the  formal 
parameter  may  then  be  used  to  reference  the  actual  parameter  within  the 
body  of  the  procedure  declaration. 

Call  by  value  and  call  by  name  apply  in  the  procedure  declarations 
of  the  proposed  language  as  they  do  in  ALGOL  60. 


5.2.2  Access  Procedures 

Access  .rocedures   access  functions)  are  similar  to  the  ALGOL  60 
functions  but  may  have  an  arbitrary  format  rather  than  a  specific  type. 
The  real,  boolean,  or  integer  procedures  (functions)  of  ALGOL  may  be 
considered  as  special  cases  of  access  procedures  whose  formats  are  real, 
boolean,  or  integer  respectively  --  "formats"  that  require  no  further 
specification.   Access  procedures,  however,  require  a  format  declaration 
to  specify  the  precise  format  of  the  function  designator. 

The  access  procedure  is  called  and  evaluated  whenever  its  function 
designator  appears  in  a  variable  which  is  not  contained  in  the  left  part 
of  an  assignment  statement.   The  variable  may  designate  the  whole  structure 
associated  with  the  function  designator  or  any  subfield  (cf.  Section  U.2.2). 
In  any  case,  the  complete  value  of  the  function  is  obtained  and  then  the  value 
of  the  designated  subfields  of  the  function  is  assigned  as  the  value  of  the 
variable.   As  with  the  ALGOL  function  declarations,  there  must  be  at  least 
one  assignment  statement  in  the  procedure  body  in  which  the  access  function 
designator  appears  in  the  left  part.   A  number  of  assignment  statements 
may  be  used  where  each  assignment  statement  assigns  the  value  of  some 
subfield  of  the  function  designator  by  making  use  of  the  structure  assigned 
by  the  format  declaration.   Every  execution  of  the  procedure  must,  however, 
define  the  value  of  every  bit  in  structure  associated  with  the  function 
designator. 
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5.2.3   Store  Procedure^ 

A  store  procedure  deviates  from  the  ALGOL  interpretation  of 
functions.   The  procedure  identifier  in  ALGOL,  which  is  a  function 
designator  when  the  procedure  defines  a  function,  serves  two  purposes. 
It  serves  to  call  the  execution  of  the  procedure  and  it  serves  as  a 
placeholder  for  the  value  of  the  function  within  the  statement  that  calls 
the  procedure.   In  every  case,  the  procedure  provides  a  value  which  is 
then  used  in  the  calling  statement.   In  addition,  these  function  calls 
may  never  occur  in  the  left  part  of  an  assignment  statement. 

Conversely,  the  appearance  of  a  store  procedure  identifier  always 
occurs  in  the  left  part  of  an  assignment  statement.   Again  the  procedure 
identifier  serves  to  call  the  execution  of  the  procedure  but  it  also  serves 
as  a  placeholder  for  information  to  be  transferred  to  the  procedure. 

As  with  access  procedures,  a  format  declaration  in  the  specification 
part  of  the  procedure  declaration  assigns  a  format  to  the  store  procedure 
identifier.   The  calling  assignment  statement  transfers  a  value  to  each 
bit  of  the  store  procedure  identifier  under  the  same  conditions  as  for 
replacing  formal  parameters  with  actual  parameters.   A  store  procedure  could 
alternately  be  viewed  as  a  pure  procedure  whose  first  formal  parameter 
is  formated  and  has  the  same  identifier  as  the  procedure  itself;  then  in  a 
store  procedure  this  first  formal  parameter  is  deleted  and  the  procedure 
identifier  is  used  instead. 

The  store  procedure  itself  transfers  the  value  of  the  procedure 
identifier  into  fields  declared  outside  of  the  procedure  declaration.   This 
is  accomplished  by  appearances  of  the  procedure  identifier  within  assignment 
tatements  in  procedure  body,  but  not  in  the  left  part  of  these  assignment 
batements.   The  structure  assigned  the  store  procedure  identifier  may  be 
to  assist  in  the  transfer  of  information  by  the  procedure. 
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The  information  flow  in  store  and  access  procedures  is  summarized 
in  Figure  2.   The  appearance  of  an  access  function  designator  as  a 
variable  serves  to  call  the  procedure  and  designate  how  the  retrieved 
information  is  to  be  used.   The  access  procedure  accepts  actual  parameters 
in  the  specified  format  and  then  transfers  information  from  declared  fields 
to  the  variable.   By  contrast,  an  assignment  statement  which  calls  a  store 
procedure  transfers  information  to  the  variable  represented  by  the  store 
function  identifier.   The  store  procedure  then  accepts  the  actual  parameters 
and  transfers  the  information  from  the  variable  to  declared  fields. 

5.3  Hardware  Interpretation 

The  primary  use  of  procedures  and  functions  in  the  proposed  language 
is  to  simplify  the  description  of  a  computer  by  providing  a  convenient 
abbreviation  for  statement  sequences  which  occur  frequently  in  the  description. 
They  also  improve  the  readability  of  the  description. 

Procedures  can  be  specifically  interpreted  in  hardware  applications 
as  defining  control  subsequences,  combinatorial  logic  functions  and  gating. 
Figure  12,  depicting  information  flow,  can  be  interpreted  for  this  purpose. 
Each  store  or  access  procedure  is  represented  by  a  block  of  logic  which  will 
include  sequencing  logic,  if  any.   A  store  procedure  takes  information 
from  an  input  bus  (formated  information  to  be  stored)  along  with  parameters 
which  are  obtained  from  the  instruction  decoding  logic  or  other  sources 
and  gates  the  information  into  a  set  of  memory  elements  (declared  fields). 
The  access  procedure  defines  the  logic  to  gate  information  from  memory 
elements  to  an  output  bus  (formated  retrieved  information) . 

Store  and  access  procedures  can  provide  the  identification  and 
description  of  specific  buses  or  data  lines.   Since  data  buses  do  not  have 
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memory  capacity  they  cannot  be  defined  by  a  field  declaration.   Buses 
reflect  the  content  of  memory  elements  and  are  assigned  a  format  through 
a  procedure  declaration. 


6.   SAMPLE  DESCRIPTION  OF  A  COMPUTER 

The  computer  which  will  be  described  in  the  proposed  language 

l 

is  essentially  taken  from  the  design  of  ILLIAC  III  [ll].   The  order  code 
has  been  reduced  and  modified  and  certain  aspects  of  the  organization 
changed  to  obtain  a  smaller,  but  complete,  machine.   This  example  is  not 
intended  to  present  a  practical  machine  but  rather  to  point  out  features 
of  the  proposed  language. 

Briefly,  the  reduced  machine  is  organized  as  follows: 
i)  A  main  store  consisting  of  l6, 777>2l6  bytes  of  memory  is 
accessed  by  a  2k   bit  address.   Each  byte  consists  of  8 
data  bits  and  a  flag  bit.   Four  base  registers  are  used  to 
define  files  containing  up  to  2^6  consecutive  pages  (256 
bytes  per  page)  in  the  main  store.   A  base  register 
designates  the  address  (high  order  l6  bits)  of  the  first 
page  and  the  total  number  of  pages  (8  bits)  in  the 
corresponding  file.   Memory  is  addressed  relative  to  a 
defined  file  by  a  l6  bit  pointer.   Eight  pointer  registers 
are  provided  for  this  purpose.   Each  pointer  register  has  a 
two  bit  base  name  which  associates  a  base  register  with 
the  pointer  register, 
ii)  All  operations  are  done  within  an  operand  stack  which 

consists  of  a  file  defined  by  a  base  register  and  a  pointer 
designating  the  next  available  byte  in  the  stack.   The 
stack  consists  of  all  bytes  from  the  beginning  of  the  file 
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to  the  byte  designated  by  pointer  1,  the  stack  pointer. 
The  length  of  the  operands  are  designated  by  a  cell  size 
field  in  the  instructions  and  may  designate  operands  of 
1,  2,  h,    and  8  bytes  in  length.   Unary  operations  apply 
to  an  operand  of  the  specified  cell  size  at  the  top  of 
the  stacks  while  binary  operations  apply  to  the  top  two 
operands ,  both  of  the  specified  cell  size.   Although  32 
bytes  of  fast  register  are  provided  to  contain  the  "upper- 
most part  of  the  stack,  all  programming  conventions  are  as 
though  the  stack  were  located  completely  in  core, 
iii)   Input/output  is  accomplished  through  a  paper  tape  reader/ 
punch.   Read  and  write  orders  are  furnished  which  transfer 
a  single  byte  between  the  operand  stack  and  reader/punch. 

The  organization  of  the  system  is  shown  in  Figure  13-   While  the 
details  of  the  order  code  should  be  clear  from  the  description  of  the 
computer  in  the  proposed  language,  the  order  code  can  be  summarized  as 
follows . 

There  are  four  basic  instruction  formats  as  shown  in  Figure  lk. 
The  ninth  or  flag  bit  of  each  instruction  byte  is  not  used.   The  tag  field 
designates  the  pointer  register  used  in  the  execution  of  the  instruction. 
The  cell  size  field  CSV  designates  the  length  of  the  operands  of  the 
instruction;  operands  lengths  are  one,  two,  four,  or  eight  bytes. 

The  four  instructions  having  format  1  are  PUSH,  POP,  LOAD,  and 
STORE.   These  instructions  transfer  a  single  operand  of  the  specifier  cell 
size  between  the  operand  stack  and  the  core  memory.   The  pointer  designated 
by  the  tag  field  is  used  (with  the  base  register  associated  with  the  pointer 
register)  to  address  core  memory.   PUSH  transfers  data  from  core  to  the  next 
empty  cell  in  the  operand  stack.   POP  transfers  data  from  the  operand  stack 
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to  core;  deleting  the  top  cell  of  the  operand  stack  after  the  transfer. 
LOAD  replaces  the  top  cell  of  the  operand  stack  with  a  cell  from  core; 
and  STORE  places  the  top  cell  of  the  stack  in  core  without  deleting  the 
cell  from  the  stack. 

The  next  four  instructions  use  a  shortened  format  2  which  does 
not  have  a  modifier.   Load  and  store  base  register  (LDBR  and  STBR)  loads 
the  base  register  designated  by  the  low  order  two  bits  of  the  tag  field 
from  the  top  cell  in  the  operand  stack  or  stores  the  base  register  in  the 
top  cell  respectively.   Store  pointer  register  (STPR)  stores  the  designated 
pointer  register  in  the  operand  stack  including  the  flags.   Load  pointer 
(LDPNT)  loads  only  the  pointer  of  the  designated  pointer  register  from  the 
operand  stack  leaving  the  original  base  name  in  the  pointer  register. 

The  next  four  instructions  use  format  2  with  a  modifier.   Set 
pointer  and  set  pointer  register  (SETPNT  and  SETPR)  transfer  the  modifier 
to  the  designated  pointer  register  with  or  without  the  flags  respectively. 
Increment  pointer  (INCR)  adds  the  modifier  to  the  designated  pointer  without 
changing  the  flags.   Compare  modifier  to  pointer  (CMPPNT)  and  set  the 
equal  and  the  equal/greater  indicators  accordingly,  while  leaving  the 
pointer  register  unchanged. 

The  READ,  WRITE,  NOP  (no  operation),  and  HALT  instructions  have 
format  3  as  well  as  the  following  set  of  four  conditional  skip  instructions: 
IFLESS  executes  the  next  instruction  only  if  the  equal/greater  indicator  is 
set;  IFEQ  and  IFGR  execute  the  next  instruction  only  if  the  equal  or  the 
equal/greater  but  not  the  equal  indicators  are  set  respectively;  IFOVFL 
executes  the  next  instruction  only  if  the  overflow  indicator  is  on  and  then 
turns  the  overflow  indicator  off. 

The  remaining  fourteen  instructions  use  format  k.      The  logical 
instructions  (AND,  OR,  EOR)  and  the  arithmetic  instructions  (ADD,  SUB, 
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MPY)  operate  on  the  top  two  cells  of  the  designated  cell  size  in  the  operand 
stack.   These  top  two  cells  are  popped  from  the  operand  stack  and  the 
result  is  then  pushed  back  into  the  stack.   The  negate  (NEG)  instruction 
replaces  the  top  cell  of  the  operand  stack  with  its  two's  complement  while 
the  complement  instruction  (COMP)  replaces  it  with  its  logical  complement. 
The  IFZERO  and  IFNEG  instructions  are  skip  type  instructions  which  execute 
the  next  instruction  only  if  the  top  cell  is  zero  or  negative  respectively. 

The  compare  instruction  (CPR)  compares  arithmetically  the  top  two 
cells  of  the  stack  and  sets  the  equal  and  equal/greater  indicators  accordingly. 
The  exchange  instruction  (EXCH)  exchanges  the  top  two  cells  of  the  operand 
stack  and  the  zero  instruction  (ZERO)  sets  the  top  cell  to  zero.   The  shift 
instruction  (SHIFT)  shifts  the  data  bits  of  the  top  cell  in  the  operand 
stack  circularly  one  bit  left. 

A  jump  instruction  is  not  required  since  pointer  register  0  is  the 
instruction  pointer  which  may  be  modified  as  any  other  pointer  register. 
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BEGIN  COMMENT  The  following  declarations  define  the  memory  requirements 

of  the  sample  computer; 

FORMAT  BASIC  INFORMATION  CELL:   BYTE(DATA  [8],  FLAG[l]); 

FIELD  CORE  MEMORY:   MEMORY(BYTE)  *  2  f  2k); 

FIELD  BASE  REGISTERS:   BR ((BYTE  *  3)  *k) ; 

FIELD  POINTER  REGISTERS:   PR ((BYTE  *  2)  *8 ) ; 

COMMENT  Up  to  32  bytes  of  the  top  of  the  operand  stack  can  be  contained  in 
the  register,  OSR.   The  number  of  bytes  of  the  stack  held  in  OSR  is  specified 
by  the  register,  OSRD.   The  operand  stack  pointer  is  P(l); 

FIELD  OPERAND  STACK  REGISTER:   OSR (BYTE  *  32),  OPERAND  STACK  REGISTER  DEPTH: 
0SRD[6]; 


COMMENT  The  following  registers  will  be  used  in  the  definition  of  the 

instructions; 

FIELD  TEMP(BYTE  *  l6),  COUNT[6],  EXB[l]; 


COMMENT  indicators; 

FIELD  OVERFLOW:   OVFL[l] ;  CONDITIONS:   COND  (GREATER  OR  EQUAL:   GEFF[l], 
EQUAL:   EQFF[1]),  BOUNDS[l]; 

COMMENT  Console  control  keys; 

FIELD  STARTKEY[1],  AUT0KEY[1],  DATAKEYS(BYTE  *3),  REGSEL[U],  INSERT[l]; 


COMMENT  The  instruction  decoding  register  is  provided  with  four  formats  for 
the  four  instruction  types; 

FIELD  INSTRUCTION  DECODING  REGISTER:   IDR(BYTE  *   3) 
OR  FIELD  TAG[3],  0P1[3],  CSV[2],  [19] 
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OR  FIELD  TAG[3],  OP2[5L  UL  MODIFIER(BYTE  *  2) 

OR  FIELD  OP3[8],  [19] 

OR  FIELD  OPl*[6],  CSV[2',  [19]; 


COMMENT  The  RDFF  and  WRTFF  are  communication  flipflops  between  the  computer 
and  the  reader/punch; 
FIELD  RDFF[l],  WRTFF [l]; 


COMMENT  The  following  procedures  define  the  pointer,  page  "base,  page  count, 
and  base  name  subfields; 

COMMENT  The  pointer  P  located  in  each  pointer  register  consists  of  the  16 

data  bits  of  the  register; 

ACCESS  PROCEDURE  P(PN);  FORMAT  P[l6],  PN[3]j 

P  :=  PR[PN].DATA; 
STORE  PROCEDURE  P(PN);  FORMAT  P[l6],  PN[3]; 

PR [PN]. DATA  :=  P; 

COMMENT  The  page  base  PGB  consists  of  the  data  bits  of  the  first  two  bytes 

of  the  base  register; 

ACCESS  PROCEDURE  PGB(BN);  FORMAT  PGB[l6],  BN[2]; 

PGB  :=  BR[BN,  0:2]. DATA; 
STORE  PROCEDURE  PGB(BN);  FORMAT  PGB[l6],  BN[2]; 

BR[BN,  0:2]. DATA  :=  PGB; 


JENT  The  page  count,  PGC,  consists  of  the  data  bits  of  the  third  byte  of 
the  base  register; 

'•;33  PROCEDURE  PGC(BN);  FORMAT  PGC[8],  BN[2]; 
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PGC  :=  BR[BN,  2]. DATA; 
STORE  PROCEDUEE  PGC(BN);  FORMAT  PGC[8],  BN[2]; 
BR[BN,  2]. DATA  :=  PGC; 

COMMENT  The  two  flag  bits  of  the  data  register  specify  the  associated  base 

register  ABR  for  each  pointer; 

ACCESS  PROCEDURE  ABR(PN);  FORMAT  ABR[2],  PN[3l; 

ABR  :=  PR[PN].FLAG; 
STORE  PROCEDURE  ABR(PN);  FORMAT  ABR[2],  PN[3]; 

PR [PN]. FLAG  :=  ABR; 

COMMENT  The  following  procedures  will  be  required  in  the  definition  of  the 
instruction  set  of  the  computer; 

COMMENT  A  fixed  length  field  (l,  2,   k,    or  8  bytes)  in  memory  may  be  accessed 

by  specifying  a  pointer  register  and  cell  size  variant; 

ACCESS  PROCEDURE  CORE(PN,  CS);  FORMAT  PN[3],  CORE(BYTE  *CS);  INTEGER  CS; 

BEGIN 

IF  PGC(ABR  (PN))  X  2  t  8  <  P(PN)  +  CS  THEN  GO  TO  BOUNDCHECK; 

CORE  :=  MEMORY [ PGB( ABR (PN))  x  2  t  8  +  P(PN)  :  CS]  END; 
STORE  PROCEDURE  CORE(PN,  CS);  FORMAT  PN[3L  CORE(BYTE  *Cc) ;      INTEGER  CS; 

BEGIN 

IF  PGC(ABR(PN))  x  2  t  8  <  P(PN)  +  CS  THEN  GO  TO  BOUNDCHECK; 

MEMORY [ PGB( ABR (PN))  x  2  t  8  +  p(PN) :   CS]  :=  CORE  END; 


COMMENT  Convert  cell  size  variant  to  cell  size; 
ACCESS  PROCEDURE  CS;  CS  :=  2  t  CSV; 
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COMMENT  TOP  obtains  the  top  cell  of  size  CS  from  the  operand  stack.   If 
the  operand  stack  register  does  not  contain  enough  information,  8  bytes 
are  brought  into  the  stack  from  core. 
ACCESS  PROCEDURE  TOP(CS);  FORMAT  TOP(BYTE  *CS)j   INTEGER  CS; 

BEGIN 

FIELD  PART [6]; 

IF  OSRD  <  CS  THEN  BEGIN 

PART  :=  P(l)  [0:13]  | |  ,0[3]'  +  8; 

IF  PGC(ABR(l))  x  2  t  8  <  PART  +  8  THEN  GO  TO  BOUNDCHECK; 

0SR[PART[11:5]  :  8]  :  = 

MEMORY [PGB[ABR(l))  x  2  t  8  +  PART  :  8]j 

OSRD  :=  OSRD  +  8 

END; 

PART  :=  P(l)  -  8; 

TOP  :=  0SR[PART[11:5]  :  IF  PART[11:5]  +  CS  >  32 

THEN  32  -  PART[11:5]  ELSE  CS]  | |  0SR[0:   IF  PART[ll:5]  +  CS  >  32  THEN 

PART[11:5]  +  CS  -  32  ELSE  0] 

END; 


COMMENT  The  store  procedure  top  places  a  cell  of  size  CS  into  the  operand 
stack.   If  the  operand  stack  register  does  not  contain  room,  8  bytes  are 
dropped  into  core. 
STORE  PROCEDURE  TOP;  FORMAT  TOP (BYTE  *CC); 

INTEGER  CS; 

BEGIN 

FIELD  PART[l6]; 

IF  OSRD  +  CS  >  32  THEN  BEGIN 
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PART  :  =  P(l)  -  31; 

PART  :=  PART[0:13]  ||  '0[3]'; 

IF  PGC(ABR(l))  x  2  t  8  <  PART  +  8  THEN  GO  TO  BOUNDCHECK; 

MEMORY  [PGB(ABR(l))  X  2  f  8  +  PART]  :=  OSR  [PART[ll:5]  :  8] 

OSRD  :=  OSRD  -  8; 

END; 

PART  :=  P(l)[0:13]  | |  '0[3]'> 

OSR  [PART[11:5]  :  IF  PART[ll:5]  +  CS  >  32  THEN 

32  -  PART[11:5]  ELSE  CS]    OSR  [0:  IF  PART[ll:5]  +  CS  >  32 


THEN  PART[11:5]  +  CS  -  32  ELSE  0] 


END; 


COMMENT  Procedure  to  place  stack  in  core; 

PROCEDURE  STACKDOWN(CELirTFT);   FORMAT  CELLSLEFT[2]; 

BEGIN 

IF  OSRD  <  CELLSLEFT  THEN  GO  TO  STD2; 
SDT1:     P(l)  :=  P(l)  -  OSRD; 

C0RE(P(1),  1)  :=  0SR[P(l)[ll:5]]; 

OSRD  :=  OSRD  -  1; 

P(l)  :=  P(l)  +  l; 

IF  OSRD  >  CELLSLEFT  THEN  GO  TO  STD1; 

P(l)  :=  P(l)  +  CELLSLEFT; 
STD2 :     END; 

COMMENT  If  the  operand  stack  pointer  is  modified  such  that  the  pointer  is  not 
at  an  integral  multiple  of  8,  the  top  part  of  the  stack  is  loaded  to  an 
integral  multiple  of  8; 
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PROCEDURE  I STACK; 

BEGIN  FIELD  PART[l6]; 

IF  P(1)[13:3]  =  0  THEN  BEGIN 

OSRD  :  =  0; 

IF  AUTOKEY  THEN  GO  TO  NEXT  ELSE  GO  TO  WAIT 

END; 

PART  :=  P(l)[0:13]  | |  '0[3]*j 

IF  PGC(ABR(l))  x  2  t  8  <  PART  +  8  THEN  GO  TO  BOUNDCHECK; 

0SR[PART[ll:5]  :  8]  :=  MEMORY [PGB(ABR(l) )  x  2  t  8  +  PART 

OSRD  :=  P(l)[ll:5] 

IF  AUTOKEY  THEN  GO  TO  NEXT  ELSE  GO  TO  WAIT  END; 
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COMMENT  The  following  section  may  be  considered  as  master  control.   The 
computer  begins  operation  with  the  statement  WAIT.   If  the  STARTKEY  is 
depressed  an  instruction  is  executed  and  the  computer  will  continue  execution 
of  instructions  while  AUTOKEY  is  set.   Manual  insertions  may  be  made  while 
the  computer  is  in  a  waiting  mode. 
WAIT:     IF  INSERT  THEN  BEGIN 

IF  REGSEL[0]  =  0  THEN  PR[REGSEL[ 1 : 3] ]   :=  DATAKEYS [ 0 : 2 ]  ELSE 

IF  REGSEL[0:2]   =  '01'  THEN  BR[REGSEL[2: 2] ]   :=  DATAKEYS; 

INSERT  :=  0; 

IF  REGSEL  ^  '0001'  THEN  ISTACK 

END 

ELSE  IF  STARTKEY  GO  TO  START  ELSE  GO  TO  WAIT; 
SKIP:     P(0)  :=  P(o)  +  1; 

IDR  :=  C0RE(0,  i+)[0:3]; 
NEXT:     IF  0P1  =  '111'  THEN  P(0)  :=  P(o)  +  3  ELSE  P(o)  :=  P(0)  +  1; 
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IF  AUTOKEY  THEN  GO  TO  START  ELSE  GO  TO  WAIT; 
BOUNDCHECK: 

BOUNDS  :=  1; 

GO  TO  HALT; 
START:    IDR  :=  CORE(0,  U)[0:3]; 


COMMENT  Begin  instruction  decoding; 

IF  OP1  =  'OOO'  THEN  GO  TO  PUSH; 

IF  0P1  =  '001*  THEN  GO  TO  POP; 

IF  0P1  =  'Oil'  THEN  GO  TO  LOAD; 

IF  0P1  =  '010'  THEN  GO  TO  STORE; 

IF  0P2  =  '11000'  THEN  GO  TO  LDBR; 

IF  0P2  =  '11001'  THEN  GO  TO  LDPNT; 

IF  0P2  =  ' 11011 '  THEN  GO  TO  STBR; 

IF  0P2  =  ' 11010 '  THEN  GO  TO  STPR; 

IF  0P2  =  '11110'  THEN  GO  TO  SETPR; 

IF  0P2  =  '11111'  THEN  GO  TO  SETPNT; 

IF  0P2  =  '11101'  THEN  GO  TO  INCR; 

IF  0P2  =  '11100'  THEN  GO  TO  CMPPNT; 

IF  0P3  =  '00010000'  THEN  GO  TO  READ; 

IF  0P3  =  '00010001'  THEN  GO  TO  WRITE; 

IF  0P3  =  '0001001'  THEN  GO  TO  NOP; 

IF  0P3  =  '00010010'  THEN  GO  TO  HALT; 

IF  0P3  =  '00010110*  THEN  GO  TO  IFLESS; 

IF  0P3  =  ' 00010111 '  THEN  GO  TO  IFGR; 

IF  0P3  =  '00010101'  THEN  GO  TO  IFEQ; 

IF  0P3  =  '00010100'  THEN  GO  TO  IFOVFL; 
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PUSH: 


IF  OPU  =  'OOllOO'  THEN  GO  TO  ADD; 
IF  OFk   =  '001101'  THEN  GO  TO  SUB; 
IF  OPk   =  '011100'  THEN  GO  TO  MPY; 
IF  OFk   =  '011101'  THEN  GO  TO  NEG; 
IF  OFk   =  '010100'  THEN  GO  TO  AND; 
IF  0P4  =  '010101'  THEN  GO  TO  OR; 
IF  OFk   =  '110100'  THEN  GO  TO  EOR; 
IF  OFk   =  '110101'  THEN  GO  TO  COMP; 
IF  OPU  =  '111100'  THEN  GO  TO  IFZERO; 
IF  OPU  =  '111101'  THEN  GO  TO  IFNEG; 
IF  OPU  =  '101100'  THEN  GO  TO  CPR; 
IF  OPU  =  ' 101101 '  THEN  GO  TO  EXCH; 
IF  0P4  =  '100100'  THEN  GO  TO  ZERO; 
IF  0P4  =  '100101'  THEN  GO  TO  SHIFT; 
IF  TAG  =  1  THEN  GO  TO  NEXT; 
P(l)  :=  P(l)  +  CS; 
ORSD  :=  ORSD  +  CS; 
TOP(CS)  :=  CORE (TAG,  CS); 
GO  TO  NEXT; 


POP:      IF  TAG  =  1  THEN  GO  TO  NEXT; 
CORE(TAG,  CS)  :=  TOP(CS); 
P(l)  :=  P(l)  -  CS; 
ORSD  :=  ORSD  -  CS; 
GO  TO  NEXT; 
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LOAD:     IF  TAG  =  1  THEN  GO  TO  NEXT; 
TOP(CS)  :=  CORE(TAG,  CS); 
GO  TO  NEXT; 


STORE:    IF  TAG  =  1  THEN  GO  TO  NEXT; 
CORE(TAG,  CS)  :=  TOP(CS); 
GO  TO  NEXT; 


COMMENT  Load  base  register; 

LDBR:     BR[TAG  [1:2]]  :=  TOP(CS)[l: 3] J 

P(l)  :=  P(l)  -  hi 

OSRD  :=  OSRD  -  k; 

GO  TO  NEXT; 

COMMENT  Load  pointer; 

LDPNT:    IF  TAG  =  1  *  OSRD  -  2  >  0  THEN  STACKD0WN(2); 

P(TAG)  :=  T0P(2).DATA; 

IF  TAG  =  1  THEN  ISTACK: 

P(l)  :=  P(l)  -  2; 

OSRD  :=  OSRD  -  2; 

IF  TAG  =  0  THEN  GO  TO  START  ELSE  GO  TO  NEXT; 


COMMENT  Store  base  register; 
STBR:     P(l)  :=  P(l)  +  k; 

OSRD  :=  OSRD  +  k} 

TOP(*0  :=  *0[9]'  ||  BR[TAG[1:2]]; 
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G0  TO  NEXT; 

COMMENT  Store  pointer  register; 
STPR:     TEMP[0:2]  :=  PR[TAG]; 

P(l)  :=  P(l)  +  kl 

OSRD  :=  OSRD  +  k; 

T0P(2)  :=  TEMP[0:2]; 

GO  TO  NEXT; 

COMMENT  Set  pointer  register; 

SETPR:    IF  TAG  =  1*  OSRD  >  0  THEN  STACKDOWN(O); 

PR [TAG]  :=  MODIFIER; 

IF  TAG  =  1  THEN  ISTACK; 

IF  TAG  =  0  THEN  GO  TO  START  ELSE  GO  TO  NEXT; 

COMMENT  Set  pointer; 

SETFNT:    IF  TAG  =  1*  OSRD  >  0  THEN  STACKDOWN(O); 

P(TAG)  :=  MODIFIER. DATA; 

IF  TAG  =  1  THEN  ISTACK; 

IF  TAG  =  0  THEN  GO  TO  START  ELSE  GO  TO  NEXT; 


COMMENT  Increment  pointer; 

INCR:     IF  TAG  =  1  THEN  STACKDOWN(O) ; 

P(TAG)  :=  P(TAG)  +  MODIFIER. DATA; 

IF  TAG  =  1  THEN  ISTACK; 

IF  TAG  =  0  THEN  GO  TO  START  ELSE  GO  TO  NEXT; 
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COMMENT  Compare  modifier  to  pointer  and  set  conditions; 
CMPPNT:    IF  MODIFIER. DATA  >  P(TAG)  THEN  GEFF  :=  1  ELSE  GEFF  : 

IF  MODIFIER. DATA  =  P(TAG)  THEN  EQFF  :«  1  ELSE  EQFF  : 

GO  TO  NEXT; 


=  0; 
=  0; 


COMMENT  Each  read  execution  takes  one  character  from  paper  tape.   RDFF  is 
set  to  indicate  RDBUFF  has  been  cleared  and  is  reset  by  tape  unit  when 
RDBUFF  is  loaded. 
READ:     IF  RDFF  =  1  THEN  GO  TO  READ; 

P(l)  :=  P(l)  +  1; 

OSRD  :=  OSRD  +  1; 

TOP(l)  :=  RDBUFF; 

RDFF  :=  1; 

GO  TO  NEXT; 

COMMENT  Each  write  execution  place  one  byte  in  WRTBUFF.   WRTFF  is  reset  when 

byte  is  punched; 

WRITE:    IF  WRTFF  =  1  THEN  GO  TO  WRITE; 

WRTBUFF  :=  TOP(l); 

WRTFF  :=  1; 

P(l)  :=  P(l)  -  l; 

OSRD  :=  OSRD  -  1; 

GO  TO  NEXT; 
NOP:  GO  TO  NEXT; 
HALT:     P(0)  :=  P(0)  +  1; 

GO  TO  WAIT; 
IFLESS:    IF  — ,GEFF  THEN  GO  TO  NEXT  ELSE  GO  TO  SKIP; 
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IFGKt     IF— »EQFF  ^  GEFF  THEN  GO  TO  NEXT  ELSE  GO  TO  SKIP; 
IFEQ:     IF  EQFF  THEN  GO  TO  NEXT  ELSE  GO  TO  SKIP; 
IFOVFL:    IF  OVFL  THEN  GO  TO  SKIP; 

OVFL  :=  0; 

GO  TO  NEXT; 


COMMENT  All  arithmetic  is  modulo  2  t  (8  x  CS).   All  numbers  may  be 
considered  positive  or  if  the  highest  order  bit  is  one  the  number  may  be 
considered  negative.   Overflow  is  indicated  on  addition. 
ADD:      TEMP[0:  CS]  :=  TOP(CS); 

P(l)  :=  P(l)  -  CS; 

OSRD  :=  OSRD  -  CS; 

EXB  ||  TOP(CS).DATA  :=  TEMP[0:  CS].DATA  +  TOP(CS) .DATA; 

IF  EXB  =  1  THEN  OVFL  :=  1; 

GO  TO  NEXT; 
SUB:      TEMP[0:  CS]  :=  TOP(CS); 

P(l)  :=  P(l)  -  CS; 

OSRD  :=  OSRD  -  CS; 

TEMP  [0:  CSj.DATA  :=  TOP(CS).DATA  -  TEMP[0:  CS].DATA; 

TOP(CS)  :=  TEMP[0:  CS]; 

GO  TO  NEXT; 
MPY:      TEMP  :=  0; 

TEMP[l6  -  CS:  CS]  :=  TOP(CS); 

P(l)  :=  P(l)  -  CS; 

OSRD  :=  OSRD  -  CS; 

COUNT  :=  8  x  CS  -  1; 

TEMP   [0:    CS].FLAG    :=  TOP(CS).FLAG 


-53- 


NEG: 


AND: 


OR: 


EOR: 


LOOP:  IF  TEMP[l6].DATA[8]  =  0  THEN 

EXB  |  |  TEMP[0:  CS]-  DATA  :=  EXB  |  | 

TEMP[0:  CS].DATA  +  TOP(CS) .DATA; 

TEMP. DATA  :=  EXB  ||  TEMP[ 0:15]- DATA  | 

EXB  :=  0; 

IF  COUNT  =  0  THEN  GO  TO  OUT; 

COUNT    :=  COUNT  -   1; 

GO  TO  LOOP; 

OUT.      TOP(CS)    :=  TEMP[0:    CS] • 

P(l)    :=  P(l)   +  CS; 

OSRD    :=   OSRD  +  CS; 

TOP(CS)       :=  TEMP[CS    :    Cr" 

GO  TO  NEXT; 

TOP(CS).DATA    :=  0   -   TOP(CS) .DATA; 

GO  TO  NEXT; 

TEMP[0:    CS]    :=  TOP(CS); 

P(l)    :=  P(l)   -   CS; 

OSRD    :=  OSRD  -   CS; 

TOP(CS)    :=   TOP(CS)   a  TEMP   [0:    CS] ; 

GO  TO  NEXT; 

TEMP[0:    CS]    :=   TOP(CS); 

P(l)    :=  P(l)    -   CS; 

OSRD    :=  OSRD  -   CS; 

TOP(CS)    :=   TOP(CS)  v  TEMP   [0    :    CS]; 

GO  TO  NEXT; 

TEMP[0:    CS]    :=   TOP(CS); 

P(l)    :=  P(l)   -  CS; 


TEMP[l6].DATA[0:7l; 
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CCMP: 

IFZERO: 

IFNEG: 

CPR: 


EXCH: 


ZERO: 


OSRD   :=  OSRD  -   CS; 

TOP(CS)    :=  'iTOP(CS)  *  TEMP[0:    CS]   v  — |TEMP[0:    CS]    *  TOP(CS); 

GO  TO  NEXT; 

TOP(CS)    :=  — |TOP(CS); 

GO  TO  NEXT; 

IF   TOP(CS)   =   0   THEN  GO  TO  NEXT  ELSE  GO  TO  SKIP; 

IF  TOP(CS)[0] .DATA[0]    =  1   THEN  GO  TO  NEXT  ELSE  GO  TO  SKIP; 

TEMP[0:    CS]    :=  TOP(CS); 

P(l)    :=  P(l)    -   CS; 

OSRD   :=  OSRD   -   CS; 

IF   TOP (CS). DATA  <  TEMP[0:    CS]].DATA  THEN  GEFF    :=  1  ELSE  GEFF    :=  0; 

IF  TOP(CS).DATA  =  TEMP[0:    CS] .DATA  THEN  EQFF    :=  1  ELSE  EQFF    :=  0; 

P(l)    :=  P(l)    +  CS; 

OSRD   :=  OSRD  +  CS; 

GO  TO  NEXT; 

TEMP[0:    CS]    :=  TOP(CS); 

P(l)    :=  P(l)    -   CS; 

OSRD   :=   OSRD   -   CS; 

TEMP[8    :    CS]    :=  TOP(CS); 

TOP(CS)    :=  TEMP[0:    CS] ; 

P(l)    :=  P(l)    +  CS; 

OSRD    :=   OSRD   +  CS; 

TOP(CS)    :=  TEMP[8:    CS] ; 

GO  TO  NEXT; 

TOP(CS)    :=  0; 

GO  TO  NEXT; 
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COMMENT  The  data  bits  of  the  top  cell  are  rotated  left  circularly  one  bit; 
SHIFT:    TEMP  [0:  CSJ.FLAG  :=  TOP(CS) .FLAG; 

EXB  ||  TEMP  [0:  CS  -  lj.DATA  ||  TEMP  [CS  -  l].DATA[0:7]  := 

TOP(CS).DATA; 
TOP(CS)  :=  TEMP  [0:  CS-l]  ||  TEMP  [CS-l].DATA  [0:7]  ||  EXB  || 
TEMP  [CS-l]. FLAG; 
END 


7-   PROBLEMS  OF  IMPLEMENTATION 


7 .1   Software  Applications 

To  indicate  how  the  proposed  language  may  be  used  in  programming 
(software)  applications,  we  will  compare  the  data  declaration 
capabilities  of  PL/l  [12],  which  also  defines  structures,  to  those  of  the 
proposed  language.   Because  of  this  degree  of  similarity,  many  aspects  of 
the  implementation  of  the  proposed  language  are  the  same  as  for  the 
implementation  of  ALGOL  or  PL/ I.   Since  many  of  these  problems  are  well 
known,  the  techniques  of  implementation  will  not  be  discussed  here. 

Data  structures  are  declared  in  PL/ I  by  a  DECLARE  statement. 
For  example,  the  PL/ I  statement 

DECLARE  JOE  FLOAT,  JIM  FIXED  (5,  3),  JACK  BIT(lO); 
declares  three  structures:   the  structure  JOE  which  is  a  floating  point 
number,  JIM  which  is  a  5  by  3  array  of  fixed  point  numbers,  and  JACK  is  a 
10  bit  field.   This  same  structure  could  be  declared  in  the  proposed 
language  by  the  following  statement. 

FIELD  JOE  (FLOAT),  JIM  (FIXED)  *3*5,  JACK  [10] 
The  format  identifiers  FLOAT  and  FIXED  designate  formats  which  are  implicitly 
declared  by  the  compiler  and  do  not  need  to  be  declared  in  the  program. 
Most  of  the  data  types  specified  by  attributes  in  PL/ I  can  be  specified  by 
implicitly  declared  formats  in  the  proposed  language. 

Arbitrary  structures  in  PL/ I  are  declared  by  prefixing  the 
structure  identifiers  with  an  integer  to  designate  the  hierarchical  level. 
For  example,  the  statement 
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DECLARE  1  A,  2  B  BIT(l6),  2  C,  3  D  (2)  BIT(8),  3  E  BIT(l6),  2  F  BIT(lO); 
is  equivalent  to  the  following  statement  in  the  proposed  language. 
FIELD  A(B[l6],  C  (D[8]*2,  E[l6]),  F[10]); 
Disjunctions  and  specifications  of  alternate  substructures  are 
not  provided  for  in  the  declarations  of  PL/l.   The  implementations  of 
these  features  are  related,  however,  to  the  implementation  of  dynamic 
storage  allocation.   The  augmented  variables  in  the  proposed  language, 
although  more  general,  are  related  to  the  concepts  of  "cross-section"  and 
"qualification"  in  PL/l.   The  store  and  access  procedures  are  extensions 
of  the  procedure  declarations  in  ALGOL  or  PL/l. 

7«  2  Introduction  of  Stack  Operations 

Although  the  information  structure  model  provides  for  the 
definition  of  stacks,  this  concept  was  not  implemented  in  the  proposed 
language.   The  use  of  stacks  is  common  in  software  applications  although 
it  is  not  provided  for  in  ALGOL  or  PL/ I. 

Iteration  can  be  introduced  into  the  data  declarations  as 
another  form  of  format  secondary  by  the  syntactic  rule: 

<format  secondary>  : :=  <format  primary >**. 
The  double  asterisk  is  used  to  distinguish  it  from  repetition  of  the 
primary.   This  form  of  format  secondary  declares  a  stack  which  is  initially 
empty.   The  use  of  the  identifier  associated  with  the  format  primary  as 
a  variable  will  then  always  refer  to  the  topmost  cell  of  the  stack  (last 
cell  inserted).   Cells  can  be  added  or  deleted  from  the  stack  by  a  variable 
in  which  the  identifier  of  the  format  primary  is  followed  by  a  slash  (/). 
If  the  variable  appears  in  the  left  part  of  an  assignment  statement  a  new 
cell  is  created,  which  becomes  the  topmost  cell,  before  the  assignment 
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occurs.   If  the  slashed  variable  occurs  elsewhere,  the  topmost  cell  is 
deleted  after  referencing  that  cell.   These  operations  correspond 
respectively  to  pushing  and  popping  the  stack. 

Let  a  stack  A  be  declared  by  the  statement 

FIELD  A [16]  **; 
The  sequence  of  statements 

A   :=  k; 

A/  :=  A; 

A/  :  =  6; 

A   :=  A/  +  A; 
causes  the  number  h   to  be  pushed  into  the  stack  and  then  duplicated.   After 
the  number  6  is  pushed  into  the  stack,  the  top  2  cells  of  the  stack  are 
added,  deleting  the  top  cell,  and  the  result  10  is  placed  back  into  the 
top  cell.   The  stack  at  the  end  of  the  sequence  consists  of  a  cell 
containing  h   followed  by  a  cell  containing  10.   The  last  statement  in  the 
sequence  is  equivalent  to  the  statement 

A/   :=  A/  +  A/; 


7« 3  Computer  Simulator 

Basically,  an  implementation  of  a  computer  simulator  is  identical 
to  an  implementation  of  a  translator  of  the  language  for  software  applications. 
Since  the  computer  is  defined  by  an  executable  program  in  the  proposed 
language,  such  a  program  may  then  be  translated  and  executed  in  the  same 
manner  as  any  other  computer  program.   In  a  practical  implementation,  some 

;  must  be  provided  for  loading  initial  instructions  and  data  into  declared 
tructures  corresponding  to  the  main  store  of  the  defined  computer.   This 
Dader  would  be  produced  by  the  translator  as  part  of  the  simulator.   Initial 


-59- 


instructions  and  data  are  then  loaded  for  each  simulation  run.   Additional 
software  should  also  be  furnished  to  provide  for  dumps  and  traces  which 
will  assist  in  locating  flaws  in  the  specification  of  the  computer. 

An  input  compiler  should  also  be  furnished  to  simulate  the 
inputs  which  occur  at  the  interfaces  between  the  computer  and  the  external 
world  in  real  time .   This  compiler  would  be  a  independent  program  which 
would  compile,  from  some  specification,  the  inputs  which  are  to  be  used 
to  test  the  defined  computer.   These  inputs  are  then  accepted  by  the 
simulator  during  the  simulation  run. 

If  an  assembly  language  for  the  defined  computer  has  been  specified, 
an  alternate  approach  to  simulation  may  be  taken.   The  description  of  the 
computer  may  be  used  to  generate  a  translator  which  translates  a  program 
written  in  the  assembly  language  for  the  defined  computer  directly  into  a 
program  to  run  on  an  existing  computer  --  without  the  intermediary  of  a 
simulator. 

This  latter  approach  may  prove  difficult  since  the  description  of  a 
new  computer  in  the  proposed  language  is  not  in  the  best  form  for  this 
purpose.   In  addition,  the  syntax  and  semantics  of  the  assembly  language  must 
also  be  provided.   The  description  of  the  defined  computer  must  be  examined 
by  the  compiler  of  the  translator  to  determine  an  equivalent  sequence  of 
instructions  for  each  source  instruction  in  the  assembly  language  of  the 
defined  computer.   Although  sufficient  information  to  perform  the  task  is 
provided  by  the  description  in  the  proposed  language,  the  translation  time 
is  likely  to  be  too  great  unless  considerable  additional  information  is 
supplied  to  the  compiler. 


7-^  Hardware  Compiler 

The  ultimate  realization  of  the  proposed  language  is  a  hardware 
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compiler  which  converts  the  description  of  a  new  computer  in  the  language 
into  specifications  of  printed  circuit  cards  (or  micro  circuit  modules), 
physical  locations  of  the  cards,  and  wiring  instructions. 

The  implementation  would  most  likely  be  broken  into  two  phases. 
The  first  phase  converts  the  specification  of  the  computer  in  the  proposed 
language  into  a  functional  description.   This  description  functionally 
specifies  all  logic  units,  sub-units  and  their  interconnections  required 
to  implement  the  computer.   The  functional  description  is  independent, 
however,  of  any  physical  allocation.   The  second  phase  partitions  the 
logic  specified  by  the  functional  description  into  component  groupings  for 
each  individual  circuit  card.   The  arrangement  and  wiring  of  the  cards  and 
the  components  on  the  cards  are  then  determined  in  a  manner  which  minimizes 
wire  length  and  meets  optimally  other  specific  electrical  and  symmetry 
conditions.   Implementations  of  second  phase  for  related  languages  have  been 
described  in  the  literature  [13,  lh]> 

In  phase  one  of  the  compilation,  the  specification  of  register  and 
memory  requirements  can  be  derived  from  the  field  declarations  in  the 
description,  while  the  gating  and  control  for  these  registers  are  determined 
by  the  specific  variables  used  to  reference  the  storage.   The  requirements 
of  functional  units  such  as  adders,  multiply/divide  units,  boolean  function 
units,  and  external  device  interfaces  can  be  determined  by  examination 
of  the  operations  used  in  the  individual  statements  of  the  description.   The 
sequencing  of  operations  follows  directly  from  the  sequence  of  statements 
in  the  descriptions.   It  is  understood  that  operations  will  be  performed 
concurrently  wherever  the  translator  determines  that  parallel  operation 
will  lead  to  a  more  optimal  design. 

It  is  unlikely  that  the  techniques  of  switching  theory  can  be 
used  to  produce  a  completely  optimal  computer  design.   The  combinatorial 
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aspects  of  these  procedures  are  too  great.   A  modular  technique  of 
construction  which  restricts  use  of  the  formal  techniques  of  switching 
theory  to  local  optimization  appears  to  be  feasible. 

A  macro-module  concept   of  computer  design  is  being  investigated 
at  Washington  University  [15  ]•   A  minimal  set  of  autonomous  logic  modules , 
capable  of  implementing  an  arbitrary  digital  computer,  is  sought.   Each 
module  contains  its  own  internal  control  and  sequencing  logic   A  "start" 
level  initiates  the  sub-operation  of  the  module,  and  the  module  furnishes 
a  "finish"  level  upon  completion  of  the  sub-operation. 

This  technique  may  suggest  a  feasible  method  of  realizing  phase 
one.   A  library  of  modules,  which  includes  the  macro-modules  but  may  also 
be  more  extensive,  would  be  developed.   These  modules  may  range  from  NAM) 
and  NOR  elements  to  adders  and  multiply/divide  units.   The  functional  descrip- 
tion of  the  computer  could  then  be  broken  into  modules.   Each  module  is 
drawn  from  the  library  or  is  in  turn  broken  into  sub-modules.   Sub-modules 
are  then  taken  from  the  library  or  again  broken  down  until  the  functional 
description  is  complete. 

The  decomposition  of  the  computer  into  modules  is  aided  by  the 
procedure  declarations  and  block  structure  of  the  language.   Although  the 
precise  form  of  the  decomposition  process  is  not  yet  known,  there  is  a 
definite  relation  between  the  modularity  of  the  logic  and  the  modularity 
specified  by  the  procedures  and  block  structure  of  the  language. 

The  block  diagram  of  store  or  access  procedures  in  Figure  12 
might  well  represent  the  module  which  is  the  implementation  of  the  procedure. 
An  additional  "start"  line  and  "finish"  line  should  be  added  to  each  block 
for  this  purpose.   The  "start"  line  is  the  physical  representation  of  the 
procedure  call  while  the  finish  line  is  the  interpretation  of  the  return 
to  the  calling  program.   Memory  defined  by  field  declarations  within  a 
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procedure  body  may  not  necessarily  define  new  registers.   The  dynamic  storage 
allocation  of  ALGOL  is  interpreted  to  mean  that  the  memory  specified  in  the 
procedure  declaration  is  only  defined  while  the  procedure  is  being  executed. 
Hence  a  pool  of  common  registers  may  be  shared  by  a  number  of  procedures. 
It  is  also  possible  that  the  memory  is  not  in  fact  required,  but  was 
declared  only  to  make  the  description  simpler. 

Although  for  the  purpose  of  definition  the  description  of  a 
computer  in  the  proposed  language  is  complete,  additional  information  will 
have  to  be  supplied  to  the  hardware  compiler.   Since  no  universal  criterion 
for  optimal  design  exists,  design  objectives  in  terms  of  speeds  and  costs 
must  be  supplied.   The  form  and  amount  of  additional  information  required 
can  only  be  determined  after  some  experience  with  the  implementation  of  the 
hardware  compiler  is  obtained. 


8.   CONCLUSION 


A  model  for  information  structures  has  been  developed  based  on 
the  regular  set  concept  of  automata  theory.   This  model  is  capable  of 
representing  information  structures  ranging  from  registers  and  buses 
of  a  digital  computer  to  complex  list  structures  of  programming  theory. 
At  the  same  time  the  model,  using  only  three  operators,  requires  a 
minimal  amount  of  notation.   In  addition,  a  set  of  information  structures 
may  be  defined.   A  specific  instance  or  member  of  the  set  may  be  selected 
as  required  to  meet  varying  conditions  such  as  variable  length  data. 
Since  the  model  draws  from  the  well  developed  theories  of  regular  sets 
and  formal  grammars,  these  areas  may  provide  a  basis  for  future  investigation 
of  a  theory  of  information  structures- 

On  the  basis  of  this  model,  the  data  declarations  and  the 
variables  of  the  ALGOL  60  programming  language  were  extended.   Although 
these  extensions  have  definite  programming  applications,  they  are  introduced 
primarily  to  describe  and  define  digital  computers.   That  is,  the  extended 
declarations  permit  information  formats  and  structures  to  be  defined  in  a 
form  which  closely  corresponds  to  the  register,  memory  and  data  buses  of 
a  digital  computer.   Convenient  and  natural  description  of  gating  in  a 
digital  computer  is  made  possible  by  the  use  of  extended  variables.   With 
these  extensions,  arithmetic,  boolean  and  data  transfer  operators  existing 
in  ALGOL  60  can  be  interpreted  to  describe  either  the  software  or  the  hard- 
ware operations  which  occur  in  a  contemporary  digital  computer. 

The  sequence  of  operations  in  the  digital  computer  follows  directly 
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from  the  sequence  of  statements  in  the  description.   Concurrent  execution  of 
operations  in  a  digital  computer  is  considered  to  be  an  aspect  of  the 
optimization  rather  than  basic  to  the  definition  of  the  computer. 

In  Chapter  6  a  simple,  but  nontrivial,  computer  has  been  completely- 
defined  in  the  proposed  language. 

Translators  for  the  language  remain  to  be  developed.  A  translator 
which  will  produce  a  simulator  of  a  computer  defined  in  the  language  can  be 
constructed  in  the  same  manner  as  translators  for  ALGOL  60  and  PL/l  and 
hence  should  present  little  additional  difficulty. 

On  the  other  hand,  a  compiler  which  will  produce  a  hardware 
implementation  of  a  computer  described  in  the  proposed  language  will  be  a 
more  difficult  task.   It  is  unlikely  that  the  exhaustive  procedures  of 
switching  theory  can  efficiently  be  used  in  the  implement  of  the  compiler 
because  these  techniques  are  marred  by  unwieldly  combinatorial  aspects. 

A  more  likely  approach  utilizes  a  hierarchy  of  modules.   Each 
module  used  in  the  implementation  is  either  drawn  from  a  library  of  modules 
or  specified  in  terms  of  component  modules.   The  modules  in  the  library  may 
range  from  individual  NAND  elements  to  multiply  units  which  are  complete  with 
sequencing  and  control.   If  a  module  is  specified  in  terms  of  component 
modules,  some  or  all  of  these  modules  may  be  taken  from  the  library  or  again 
broken  down  until  the  computer  is  completely  specified.   The  division  of  the 
computer  into  modules  is  determined  by  the  procedures,  block  structure  and 
and  statement  construction  of  the  description  in  the  language. 

A  primary  problem  in  the  implementation  of  the  hardware  compiler  will 
be  the  specification  of  the  library  and  methods  of  breaking  up  modules.   The 
experience  gained  in  the  development  of  the  library  and  compiler  may  eventually 
bring  about  a  fundamental  reorganization  in  the  concepts  and  teaching  of 
arputer  design  --  as  switching  theory  is  integrated  with  system  programming. 
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